Granular segmentation using events

ABSTRACT

Methods and systems for granular segmentation of data networks are provided herein. Exemplary methods include: receiving from a metadata source event metadata associated with a workload; identifying a workload type using the event metadata; determining a high-level declarative security policy using the workload type; launching a compiler to generate a low-level firewall rule set using the high-level declarative policy and the event metadata; and configuring by a plurality of enforcement points a respective network switch of a plurality of network switches to process packets in accordance with the low-level firewall ruleset, the network switches being collectively communicatively coupled to a plurality of workloads, such that network communications between a first group of workloads of the plurality of workloads and the workload are not permitted, and between a second group of workloads of the plurality of workloads and the workload are permitted.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of U.S. patent applicationSer. No. 15/192,967, filed Jun. 24, 2016, the disclosure of which ishereby incorporated by reference for all purposes.

FIELD OF THE INVENTION

The present technology pertains to computer security, and morespecifically to computer network security.

BACKGROUND ART

A hardware firewall is a network security system that controls incomingand outgoing network traffic. A hardware firewall generally creates abarrier between an internal network (assumed to be trusted and secure)and another network (e.g., the Internet) that is assumed not to betrusted and secure.

Attackers breach internal networks to steal critical data. For example,attackers target low-profile assets to enter the internal network.Inside the internal network and behind the hardware firewall, attackersmove laterally across the internal network, exploiting East-West trafficflows, to critical enterprise assets. Once there, attackers siphon offvaluable company and customer data.

SUMMARY OF THE INVENTION

Some embodiments of the present technology include methods for granularsegmentation of data networks which may include: receiving from ametadata source event metadata associated with a workload; identifying aworkload type using the event metadata; determining a high-leveldeclarative security policy using the workload type; launching acompiler to generate a low-level firewall rule set using the high-leveldeclarative policy and the event metadata; and configuring by aplurality of enforcement points a respective network switch of aplurality of network switches to process packets in accordance with thelow-level firewall ruleset, the network switches being collectivelycommunicatively coupled to a plurality of workloads, such that networkcommunications between a first group of workloads of the plurality ofworkloads and the workload are not permitted, and between a second groupof workloads of the plurality of workloads and the workload arepermitted.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like reference numerals refer toidentical or functionally similar elements throughout the separateviews, together with the detailed description below, are incorporated inand form part of the specification, and serve to further illustrateembodiments of concepts that include the claimed disclosure, and explainvarious principles and advantages of those embodiments. The methods andsystems disclosed herein have been represented where appropriate byconventional symbols in the drawings, showing only those specificdetails that are pertinent to understanding the embodiments of thepresent disclosure so as not to obscure the disclosure with details thatwill be readily apparent to those of ordinary skill in the art havingthe benefit of the description herein.

FIG. 1 is a simplified block diagram of an (physical) environment,according to some embodiments.

FIG. 2 is a simplified block diagram of an (virtual) environment, inaccordance with some embodiments.

FIG. 3 is a simplified block diagram of an environment, according tovarious embodiments.

FIG. 4 is a simplified block diagram of an environment, in accordancewith various embodiments.

FIG. 5A illustrates example metadata, according to some embodiments.

FIG. 5B is a table of example expected behaviors in accordance with someembodiments.

FIG. 6 is a simplified block diagram of a system, according to variousembodiments.

FIG. 7 is a flow diagram of a method, in accordance with variousembodiments.

FIG. 8 is a simplified block diagram of a microsegmented computernetwork, according some embodiments.

FIG. 9 is a simplified block diagram of a computer system, in accordancewith some embodiments.

FIG. 10 is a simplified block diagram of a system, in accordance withvarious embodiments.

FIG. 12 is a flow diagram of a method, according to some embodiments.

DETAILED DESCRIPTION

While this technology is susceptible of embodiment in many differentforms, there is shown in the drawings and will herein be described indetail several specific embodiments with the understanding that thepresent disclosure is to be considered as an exemplification of theprinciples of the technology and is not intended to limit the technologyto the embodiments illustrated. The terminology used herein is for thepurpose of describing particular embodiments only and is not intended tobe limiting of the technology. As used herein, the singular forms “a,”“an,” and “the” are intended to include the plural forms as well, unlessthe context clearly indicates otherwise. It will be further understoodthat the terms “comprises,” “comprising,” “includes,” and/or“including,” when used in this specification, specify the presence ofstated features, integers, steps, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operations, elements, components,and/or groups thereof. It will be understood that like or analogouselements and/or components, referred to herein, may be identifiedthroughout the drawings with like reference characters. It will befurther understood that several of the figures are merely schematicrepresentations of the present technology. As such, some of thecomponents may have been distorted from their actual scale for pictorialclarity.

Information technology (IT) organizations face cyber threats andadvanced attacks. Firewalls are an important part of network security.Firewalls control incoming and outgoing network traffic using a ruleset. A rule, for example, allows a connection to a specific (InternetProtocol (IP)) address (and/or port), allows a connection to a specific(IP) address (and/or port) if the connection is secured (e.g., usingInternet Protocol security (IPsec)), blocks a connection to a specific(IP) address (and/or port), redirects a connection from one IP address(and/or port) to another IP address (and/or port), logs communicationsto and/or from a specific IP address (and/or port), and the like. Afirewall rule at a low level of abstraction may indicate a specific (IP)address and protocol to which connections are allowed and/or notallowed.

Managing a set of firewall rules is a difficult challenge. Some ITsecurity organizations have a large staff (e.g., dozens of staffmembers) dedicated to maintaining firewall policy (e.g., a firewall ruleset). A firewall rule set can have tens of thousands or even hundreds ofthousands of rules. Some embodiments of the present technology mayautonomically generate a reliable declarative security policy at a highlevel of abstraction. Abstraction is a technique for managing complexityby establishing a level of complexity which suppresses the more complexdetails below the current level. The high-level declarative policy maybe compiled to produce a firewall rule set at a low level ofabstraction.

FIG. 1 illustrates a system 100 according to some embodiments. System100 includes network 110 and data center 120. In various embodiments,data center 120 includes firewall 130, optional core switch/router (alsoreferred to as a core device) 140, Top of Rack (ToR) switches 150 ₁-150_(x), and physical hosts 160 _(1,1)-160 _(x,y).

Network 110 (also referred to as a computer network or data network) isa telecommunications network that allows computers to exchange data. Forexample, in network 110, networked computing devices pass data to eachother along data connections (e.g., network links). Data can betransferred in the form of packets. The connections between nodes may beestablished using either cable media or wireless media. For example,network 110 includes at least one of a local area network (LAN),wireless local area network (WLAN), wide area network (WAN),metropolitan area network (MAN), and the like. In some embodiments,network 110 includes the Internet.

Data center 120 is a facility used to house computer systems andassociated components. Data center 120, for example, comprises computingresources for cloud computing services or operated for the benefit of aparticular organization. Data center equipment, for example, isgenerally mounted in rack cabinets, which are usually placed in singlerows forming corridors (e.g., aisles) between them. Firewall 130 createsa barrier between data center 120 and network 110 by controllingincoming and outgoing network traffic based on a rule set.

Optional core switch/router 140 is a high-capacity switch/router thatserves as a gateway to network 110 and provides communications betweenToR switches 150 ₁ and 150 _(x), and between ToR switches 150 ₁ and 150_(x) and network 110. ToR switches 150 ₁ and 150 _(x) connect physicalhosts 160 _(1,1)-160 _(1,y) and 160 _(x,1)-160 _(x,y) (respectively)together and to network 110 (optionally through core switch/router 140).For example, ToR switches 150 ₁-150 _(x) use a form of packet switchingto forward data to a destination physical host (of physical hosts 160_(1,1)-160 _(x,y)) and (only) transmit a received message to thephysical host for which the message was intended.

In some embodiments, physical hosts 160 _(1,1)-160 _(x,y) are computingdevices that act as computing servers such as blade servers. Computingdevices are described further in relation to FIG. 7. For example,physical hosts 160 _(1,1)-160 _(x,y) comprise physical serversperforming the operations described herein, which can be referred to asa bare-metal server environment. Additionally or alternatively, physicalhosts 160 _(1,1)-160 _(x,y) may be a part of a cloud computingenvironment. Cloud computing environments are described further inrelation to FIG. 7. By way of further non-limiting example, physicalhosts 160 _(1,1)-160 _(x,y) can host different combinations andpermutations of virtual and container environments (which can bereferred to as a virtualization environment), which are describedfurther below in relation to FIGS. 2-4.

FIG. 2 depicts (virtual) environment 200 according to variousembodiments. In some embodiments, environment 200 is implemented in atleast one of physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1). Environment200 includes hardware 210, host operating system (OS) 220, hypervisor230, and virtual machines (VMs) 260 ₁-260 _(V). In some embodiments,hardware 210 is implemented in at least one of physical hosts 160_(1,1)-160 _(x,y) (FIG. 1). Host operating system 220 can run onhardware 210 and can also be referred to as the host kernel. Hypervisor230 optionally includes virtual switch 240 and includes enforcementpoints 250 ₁-250 _(V). VMs 260 ₁-260 _(V) each include a respective oneof operating systems (OSes) 270 ₁-270 _(V) and applications (APPs) 280₁-280 _(V).

Hypervisor (also known as a virtual machine monitor (VMM)) 230 issoftware running on at least one of physical hosts 160 _(1,1)-160_(x,y), and hypervisor 230 runs VMs 260 ₁-260 _(V). A physical host (ofphysical hosts 160 _(1,1)-160 _(x,y)) on which hypervisor 230 is runningone or more virtual machines 260 ₁-260 _(V), is also referred to as ahost machine. Each VM can also be referred to as a guest machine.

For example, hypervisor 230 allows multiple OSes 270 ₁-270 _(V) to sharea single physical host (of physical hosts 160 _(1,1)-160 _(x,y)). Eachof OSes 270 ₁-270 _(V) appears to have the host machine's processor,memory, and other resources all to itself. However, hypervisor 230actually controls the host machine's processor and resources, allocatingwhat is needed to each operating system in turn and making sure that theguest OSes (e.g., virtual machines 260 ₁-260 _(V)) cannot disrupt eachother. OSes 270 ₁-270 _(V) are described further in relation to FIG. 7.

VMs 260 ₁-260 _(V) also include applications 280 ₁-280 _(V).Applications (and/or services) 280 ₁-280 _(V) are programs designed tocarry out operations for a specific purpose. Applications 280 ₁-280 _(V)can include at least one of web application (also known as web apps),web server, transaction processing, database, and the like software.Applications 280 ₁-280 _(V) run using a respective OS of OSes 270 ₁-270_(V).

Hypervisor 230 can include virtual switch 240. Virtual switch 240 is alogical switching fabric for networking VMs 260 ₁-260 _(V). For example,virtual switch 240 is a program running on a physical host (of physicalhosts 160 _(1,1)-160 _(x,y)) that allows a VM (of VMs 260 ₁-260 _(V)) tocommunicate with another VM.

Hypervisor 230 also includes enforcement points 250 ₁-250 _(V),according to some embodiments. For example, enforcement points 250 ₁-250_(V) are a firewall service that provides network traffic filtering andmonitoring for VMs 260 ₁-260 _(V) and containers (described below inrelation to FIGS. 3 and 4). Enforcement points 250 ₁-250 _(V) aredescribed further in related United States Patent Application “Methodsand Systems for Orchestrating Physical and Virtual Switches to EnforceSecurity Boundaries” (application Ser. No. 14/677,827) filed Apr. 2,2015, which is hereby incorporated by reference for all purposes.Although enforcement points 250 ₁-250 _(V) are shown in hypervisor 230,enforcement points 250 ₁-250 _(V) can additionally or alternatively berealized in one or more containers (described below in relation to FIGS.3 and 4).

According to some embodiments, enforcement points 250 ₁-250 _(V) controlnetwork traffic to and from a VM (of VMs 260 ₁-260 _(V)) (and/or acontainer) using a rule set. A rule, for example, allows a connection toa specific (IP) address, allows a connection to a specific (IP) addressif the connection is secured (e.g., using IPsec), denies a connection toa specific (IP) address, redirects a connection from one IP address toanother IP address (e.g., to a honeypot or tar pit), logs communicationsto and/or from a specific IP address, and the like. Each address isvirtual, physical, or both. Connections are incoming to the respectiveVM (or a container), outgoing from the respective VM (or container), orboth. Redirection is described further in related United States PatentApplication “System and Method for Threat-Driven Security PolicyControls” (application Ser. No. 14/673,679) filed Mar. 30, 2015, whichis hereby incorporated by reference for all purposes.

In some embodiments logging includes metadata associated with actiontaken by an enforcement point (of enforcement points 250 ₁-250 _(V)),such as the permit, deny, and log behaviors. For example, for a DomainName System (DNS) request, metadata associated with the DNS request, andthe action taken (e.g., permit/forward, deny/block, redirect, and logbehaviors) are logged. Activities associated with other(application-layer) protocols (e.g., Dynamic Host Configuration Protocol(DHCP), Domain Name System (DNS), File Transfer Protocol (FTP),Hypertext Transfer Protocol (HTTP), Internet Message Access Protocol(IMAP), Post Office Protocol (POP), Secure Shell (SSH), Secure SocketsLayer (SSL), Transport Layer Security (TLS), telnet, Remote DesktopProtocol (RDP), Server Message Block (SMB), and the like) and theirrespective metadata may be additionally or alternatively logged. Forexample, metadata further includes at least one of a source (IP) addressand/or hostname, a source port, destination (IP) address and/orhostname, a destination port, protocol, application, and the like.

FIG. 3 depicts environment 300 according to various embodiments.Environment 300 includes hardware 310, host operating system 320,container engine 330, containers 340 ₁-340 _(z), virtual switch 240, ToRswitch 150, and enforcement point 250. In some embodiments, hardware 310is implemented in at least one of physical hosts 160 _(1,1)-160 _(x,y)(FIG. 1). Host operating system 320 runs on hardware 310 and can also bereferred to as the host kernel. By way of non-limiting example, hostoperating system 320 can be at least one of: Linux, Red Hat® EnterpriseLinux® Atomic Enterprise Platform, CoreOS®, Ubuntu® Snappy, PivotalCloud Foundry®, Oracle® Solaris, and the like. Host operating system 320allows for multiple (instead of just one) isolated user-space instances(e.g., containers 340 ₁-340 _(z)) to run in host operating system 320(e.g., a single operating system instance).

Host operating system 320 can include a container engine 330. Containerengine 330 can create and manage containers 340 ₁-340 _(z), for example,using an (high-level) application programming interface (API). By way ofnon-limiting example, container engine 330 is at least one of Docker®,Rocket (rkt), Solaris Containers, and the like. For example, containerengine 330 may create a container (e.g., one of containers 340 ₁-340_(z)) using an image. An image can be a (read-only) template comprisingmultiple layers and can be built from a base image (e.g., for hostoperating system 320) using instructions (e.g., run a command, add afile or directory, create an environment variable, indicate what process(e.g., application or service) to run, etc.). Each image may beidentified or referred to by an image type. In some embodiments, images(e.g., different image types) are stored and delivered by a system(e.g., server side application) referred to as a registry or hub (notshown in FIG. 3).

Container engine 330 can allocate a filesystem of host operating system320 to the container and add a read-write layer to the image. Containerengine 330 can create a network interface that allows the container tocommunicate with hardware 310 (e.g., talk to a local host). Containerengine 330 can set up an Internet Protocol (IP) address for thecontainer (e.g., find and attach an available IP address from a pool).Container engine 330 can launch a process (e.g., application or service)specified by the image (e.g., run an application, such as one of APP 350₁-350 _(z), described further below). Container engine 330 can captureand provide application output for the container (e.g., connect and logstandard input, outputs and errors). The above examples are only forillustrative purposes and are not intended to be limiting.

Containers 340 ₁-340 _(z) can be created by container engine 330. Insome embodiments, containers 340 ₁-340 _(z), are each an environment asclose as possible to an installation of host operating system 320, butwithout the need for a separate kernel. For example, containers 340₁-340 _(z) share the same operating system kernel with each other andwith host operating system 320. Each container of containers 340 ₁-340_(z) can run as an isolated process in user space on host operatingsystem 320. Shared parts of host operating system 320 can be read only,while each container of containers 340 ₁-340 _(z) can have its own mountfor writing.

Containers 340 ₁-340 _(z) can include one or more applications (APP) 350₁-350 _(z) (and all of their respective dependencies). APP 350 ₁-350_(z) can be any application or service. By way of non-limiting example,APP 350 ₁-350 _(z) can be a database (e.g., Microsoft® SQL Server®,MongoDB, HTFS, MySQL®, Oracle® database, etc.), email server (e.g.,Sendmail®, Postfix, qmail, Microsoft® Exchange Server, etc.), messagequeue (e.g., Apache® Qpid™, RabbitMQ®, etc.), web server (e.g., Apache®HTTP Server™, Microsoft® Internet Information Services (IIS), Nginx,etc.), Session Initiation Protocol (SIP) server (e.g., Kamailio® SIPServer, Avaya® Aura® Application Server 5300, etc.), other media server(e.g., video and/or audio streaming, live broadcast, etc.), file server(e.g., Linux server, Microsoft® Windows Server®, Network File System(NFS), HTTP File Server (HFS), Apache® Hadoop®, etc.), service-orientedarchitecture (SOA) and/or microservices process, object-based storage(e.g., Lustre®, EMC® Centera, Scality® RING®, etc.), directory service(e.g., Microsoft® ActiveDirectory®, Domain Name System (DNS) hostingservice, etc.), monitoring service (e.g., Zabbix®, Qualys®, HP® BusinessTechnology Optimization (BTO; formerly OpenView), etc.), logging service(e.g., syslog-ng, Splunk®, etc.), and the like.

Virtual switch 240 is a logical switching fabric for networkingcontainers 340 ₁-340 _(z). For example, virtual switch allows acontainer (of containers 340 ₁-340 _(z)) to communicate with anothercontainer. By way of further non-limiting example, virtual switch 240 iscommunicatively coupled to ToR switch 150. In this way, containers 340₁-340 _(z) can communicate with other devices such as VMs (e.g., VMs 260₁-260 _(V) (FIG. 2)) and bare-metal servers (e.g., within data center120 and/or over network 110 (FIG. 1)). In some embodiments, virtualswitch 240 executes as a part of host operating system 320.

Enforcement point 250 can be run in a container (e.g., of containers 340₁-340 _(z)) and/or a VM (of VMs 260 ₁-260 _(V)). In some embodiments,enforcement point 250 is advantageously run on a container close inphysical proximity to other containers whose communications arecontrolled by enforcement 250. As shown in FIG. 3, virtual switch 240can be communicatively coupled to enforcement point 250.

Enforcement point 250 can program virtual switch 240 to controlcommunications flow (e.g., data packets) to, from, and among containers340 ₁-340 _(z). In various embodiments, virtual switch 240 can beprogrammed to forward communications directed to and/or from containers340 ₁-340 _(z) to enforcement point 250 for analysis. In other words,virtual switch 240 can be programmed such that communications traffic(e.g., data packets) are forwarded to enforcement point 250. Forexample, enforcement point 250 programs forwarding rules into virtualswitch 240. By way of further non-limiting example, enforcement point250 programs overflow rules and/or deploys a Linux bridge topology intovirtual switch 240. As described above in relation to FIG. 2,enforcement point 250 can control network traffic to and from containers340 ₁-340 _(z), for example, using a rule set.

Enforcement point 250 can analyze communications traffic (e.g., datapackets) forwarded by virtual switch 240. In some embodiments,enforcement point 250 can perform stateful packet inspection (SPI),stateless, and application aware inspection of the forwardedcommunications traffic. Stateful packet inspection can watch trafficstreams from end to end and be aware of current communication paths(e.g., data traffic patterns and/or flows). Stateless packet inspectioncan rely on source and destination addresses or other static values.Application aware inspection includes, for example, AppID (describedbelow).

Each of VMs 260 ₁-260 _(V) (FIG. 2) and containers 340 ₁-340 _(z) can bereferred to as workloads and/or endpoints. In contrast tohypervisor-based virtualization VMs 260 ₁-260 _(V), containers 340 ₁-340_(z) may be an abstraction performed at the operating system (OS) level,whereas VMs are an abstraction of physical hardware. Since VMs 260 ₁-260_(V) can virtualize hardware, each VM instantiation of VMs 260 ₁-260_(V) can have a full server hardware stack from virtualized BasicInput/Output System (BIOS) to virtualized network adapters, storage, andcentral processing unit (CPU). The entire hardware stack means that eachVM of VMs 260 ₁-260 _(V) needs its own complete OS instantiation andeach VM must boot the full OS. Although FIG. 3 depicts containers 340₁-340 _(z) running on hardware 310 (e.g., a physical host of physicalhosts 160 _(1,1)-160 _(x,y) (FIG. 1)), host operating system 320,container engine 330, and containers 340 ₁-340 _(z) may additionally oralternatively run on a VM (e.g., one of VMs 260 ₁-260 _(V) (FIG. 2)).

FIG. 4 illustrates environment 400, according to some embodiments.Environment 400 can include security director 450, environments 300₁-300 _(W), orchestration layer 410, metadata 430, and models (and/orcategorizations) 440. Environments 300 ₁-300 _(W) can be instances ofenvironment 300 (FIG. 3), include containers 340 _(1,1)-340 _(W,Z), andbe in at least one of data center 120 (FIG. 1). Containers 340_(1,1)-340 _(W,Z) (e.g., in a respective environment of environments 300₁-300 _(W)) can be a container as described in relation to containers340 ₁-340 _(Z) (FIG. 3).

Orchestration layer 410 can manage and deploy containers 340 _(1,1)-340_(W,Z) across one or more environments 300 ₁-300 _(W) in one or moredata centers of data center 120 (FIG. 1). In some embodiments, to manageand deploy containers 340 _(1,1)-340 _(W,Z), orchestration layer 410receives one or more image types (e.g., named images) from a datastorage and content delivery system referred to as a registry or hub(not shown in FIG. 4). By way of non-limiting example, the registry canbe the Google Container Registry. In various embodiments, orchestrationlayer 410 determines which environment of environments 300 ₁-300 _(W)should receive each container of containers 340 _(1,1)-340 _(W,Z) (e.g.,based on the environments' 300 ₁-300 _(W) current workload and a givenredundancy target). Orchestration layer 410 can provide means ofdiscovery and communication between containers 340 _(1,1)-340 _(W,Z).According to some embodiments, orchestration layer 410 runs virtually(e.g., in one or more containers 340 _(1,1)-340 _(W,Z) orchestrated by adifferent one of orchestration layer 410 and/or in one or more ofhypervisor 230 (FIG. 2)) and/or physically (e.g., in one or morephysical hosts of physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1) in oneor more of data center 120. By way of non-limiting example,orchestration layer 410 is at least one of Docker Swarm®, Kubernetes®,Cloud Foundry® Diego, Apache® Mesos™, and the like.

Orchestration layer 410 can maintain (e.g., create and update) metadata430. Metadata 430 can include reliable and authoritative metadataconcerning containers (e.g., containers 340 _(1,1)-340 _(W,Z)). FIG. 5Aillustrates metadata example 500A, a non-limiting example of metadata430 (FIG. 4). By way of illustration, metadata example 500A indicatesfor a container at least one of: an image name (e.g., file nameincluding at least one of a network device (such as a host, node, orserver) that contains the file, hardware device or drive, directory tree(such as a directory or path), base name of the file, type (such asformat or extension) indicating the content type of the file, andversion (such as revision or generation number of the file), an imagetype (e.g., including name of an application or service running), themachine with which the container is communicating (e.g., IP address,host name, etc.), and a respective port through which the container iscommunicating, and other tag and/or label (e.g., a (user-configurable)tag or label such as a Kubernetes® tag, Docker® label, etc.), and thelike. In various embodiments, metadata 430 is generated by orchestrationlayer 410—which manages and deploys containers—and can be very timely(e.g., metadata is available soon after an associated container iscreated) and highly reliable (e.g., accurate). In addition oralternative to metadata example 500A, other metadata may comprisemetadata 430 (FIG. 4). For example, other elements (e.g., service name,user-configurable tag and/or label, and the like) associated with models440 are used. By way of further non-limiting example, metadata 430includes an application determination using application identification(AppID). AppID can process data packets at a byte level and can employsignature analysis, protocol analysis, heuristics, and/or behavioralanalysis to identify an application and/or service. In some embodiments,AppID inspects only a part of a data payload (e.g., only parts of someof the data packets). By way of non-limiting example, AppID is at leastone of Cisco Systems® OpenAppID, Qosmos ixEngine®, Palo Alto Networks®APP-ID™, and the like.

Referring back to FIG. 4, security director 450 can receive metadata430, for example, through application programming interface (API) 420.Other interfaces can be used to receive metadata 430. In someembodiments, security director 450 can include models 440. Models 440can include a model of expected (network communications) behavior for animage type. For example, expected (network communications) behaviors caninclude at least one of: protocols and/or ports that should be used by acontainer and who the container should talk to (e.g., relationshipsbetween containers, such as other applications and/or services thecontainer should talk to), and the like.

In some embodiments, models 440 include a model of expected (networkcommunications) behavior for applications and/or services running in aVM (e.g., of VMs 260 ₁-260 _(V) shown in FIG. 2). In variousembodiments, models 440 are modifiable by an operator, such thatsecurity policy is adapted to the evolving security challengesconfronting the IT organization. For example, the operator providespermitted and/or forbidden (network communications) behaviors via atleast one of a graphical user interface (GUI), command-line interface(CLI), application programming interface (API), and the like (notdepicted in FIG. 4).

FIG. 5B shows table 500B representing model 440 including non-limitingexamples of expected behaviors, according to some embodiments. Forexample, database server 510B can be expected to communicate usingtransmission control protocol (TCP), common secure managementapplications, and Internet Small Computer System (iSCSI) TCP. By way offurther non-limiting example, database server 510B can be expected tocommunicate with application servers, other database servers,infrastructure management devices, and iSCSI target. In someembodiments, if database server 510B were to communicate with a userdevice using Hypertext Transfer Protocol (HTTP), then such a deviationfrom expected behavior could be used at least in part to detect asecurity breach.

By way of additional non-limiting example, file server 520B (e.g., HTTPFile Server or HFS) can be expected to communicate using HTTP and commonsecure management applications. For example, file server 520B can beexpected to communicate with application servers and infrastructuremanagement devices. In various embodiments, if file server 520B were tocommunicate with a user device using Hypertext Transfer Protocol (HTTP),then such a deviation from expected behavior could be used at least inpart to detect a security breach.

Many other deviations from expected behavior are possible. Additionally,other different combinations and/or permutations of services, protocols(e.g., Advanced Message Queuing Protocol (AMQP), DNS, Dynamic HostConfiguration Protocol (DHCP), Network File System (NFS), Server MessageBlock (SMB), User Datagram Protocol (UDP), and the like) and commonports, communication partners, direction, and application payload and/ormessage semantics (e.g., Secure Shell (SSH), Internet Control MessageProtocol (ICMP), Structured Query Language (SQL), and the like),including ones not depicted in FIG. 5B may be used. Security director450 can be at least one of a bare-metal server, virtual machine, andcontainer.

Referring back to FIG. 4, using metadata 430 and models 440, securitydirector 450 applies heuristics to generate a high-level declarativesecurity policy associated with a container (e.g., of containers 340_(1,1)-340 _(W,Z)), according to some embodiments. A high-level securitypolicy can comprise one or more high-level security statements, wherethere is one high-level security statement per allowed protocol, port,and/or relationship combination. In some embodiments, security director450 determines an image type using metadata 430 and matches the imagetype with one or more models 440 associated with the image type. Forexample, if/when the image type corresponds to a certain databaseapplication, then one or more models associated with that database aredetermined. A list of at least one of: allowed protocols, ports, andrelationships for the database may be determined using the matchedmodel(s).

In various embodiments, security director 450 produces a high-leveldeclarative security policy for the container using the list of at leastone of: allowed protocols, ports, and relationships. The high-leveldeclarative security policy can be at least one of: a statement ofprotocols and/or ports the container is allowed to use, indicateapplications/services that the container is allowed to communicate with,and indicate a direction (e.g., incoming and/or outgoing) of permittedcommunications. According to some embodiments, singleapplication/service is subsequently used to identify several differentmachines associated with the single application/service. The high-leveldeclarative security policy is at a high level of abstraction, incontrast with low-level firewall rules, which are at a low level ofabstraction and only identify specific machines by IP address and/orhostname. Accordingly, one high-level declarative security statement canbe compiled to produce hundreds or more of low-level firewall rules.

The high-level security policy can be compiled by security director 450(or other machine) to produce a low-level firewall rule set. Compilationis described further in related United States Patent Application“Conditional Declarative Policies” (application Ser. No. 14/673,640)filed Mar. 30, 2015, which is hereby incorporated by reference for allpurposes.

According to some embodiments, a low-level firewall rule set is used byenforcement point 250 (FIGS. 2 and 3) to determine when the high-levelsecurity policy is (possibly) violated. For example, a database (e.g.,in a container of containers 340 _(1,1)-340 _(W,Z)) serving web pagesusing the Hypertext Transfer Protocol (HTTP) and/or communicating withexternal networks (e.g., network 110 of FIG. 1) could violate ahigh-level declarative security policy for that database container. Invarious embodiments, enforcement point 250 is an enforcement point(e.g., in a container of containers 340 _(1,1)-340 _(W,Z)). Enforcementpoints are described further in related United States Patent Application“Methods and Systems for Orchestrating Physical and Virtual Switches toEnforce Security Boundaries” (application Ser. No. 14/677,827) filedApr. 2, 2015, which is hereby incorporated by reference for allpurposes. Detection of a (potential) violation of the high-levelsecurity policy and violation handling are described further in relatedUnited States Patent Application “System and Method for Threat-DrivenSecurity Policy Controls” (application Ser. No. 14/673,679) filed Mar.30, 2015, which is hereby incorporated by reference for all purposes.For example, when a (potential) violation of the high-level securitypolicy is detected, enforcement point 250 (or other machine) issues analert and/or drops/forwards network traffic that violates the high-leveldeclarative security policy.

FIG. 6 illustrates a simplified block diagram of system 600, accordingto some embodiments. System 600 may include security director 450,policy 620, analytics 630, log 640, management 650, orchestration layer410, and enforcement points 250 ₁-250 _(U). Enforcement points 250 ₁-250_(U) have at least some of the characteristics described above forenforcement points 250 ₁-250 _(V) (FIG. 2) and enforcement point 250(FIG. 3).

Security director 450 can receive metadata from orchestration layer 410(FIG. 4). For example, as described above in relation to FIG. 4,metadata from orchestration layer 410 can be reliable and authoritativemetadata concerning containers, network topology, and the like (e.g.,metadata 430 (FIG. 4). For example, when a container (e.g., ofcontainers 340 ₁-340 _(z) (FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4))is deployed, the container is assigned an (IP) address, which may beincluded in metadata received from orchestration layer 410.

Security director 450 can also be communicatively coupled to enforcementpoints 250 ₁-250 _(U). For example, security director 450 disseminatesrespective low-level firewall rule sets to enforcement points 250 ₁-250_(U), each firewall rule sets applicable to a respective one ofenforcement points 250 ₁-250 _(U). By way of further non-limitingexample, security director 450 receives information logged byenforcement points 250 ₁-250 _(U), as described above in relation toFIG. 2 and stores it in log 640.

According to some embodiments, policy 620 is a data store of high-leveldeclarative security policies and/or low-level firewall rule sets. Adata store can be a repository for storing and managing collections ofdata such as databases, files, and the like, and can include anon-transitory storage medium (e.g., mass data storage 930, portablestorage device 940, and the like described in relation to FIG. 9).

In various embodiments, analytics 630 provides computational analysisfor data network security. For example, analytics 630 compileshigh-level declarative security policies into low-level firewall rulesets. By way of further non-limiting example, analytics 630 analyzes log640 for malicious behavior, and the like.

In accordance with some embodiments, log 640 is a data store ofinformation logged by enforcement points 250 ₁-250 _(U), as describedabove in relation to FIG. 2. A data store can be a repository forstoring and managing collections of data such as databases, files, andthe like, and can include a non-transitory storage medium (e.g., massdata storage 930, portable storage device 940, and the like described inrelation to FIG. 9).

Management 650 can dynamically commission (spawn/launch) and/ordecommission instances of security director 450 and/or enforcementpoints 250 ₁-250 _(U). In this way, computing resources can bedynamically added to, reallocated in, and removed from an associateddata network, and microsegmentation is maintained. For example, ascontainers (e.g., of containers 340 ₁-340 _(Z) (FIG. 3)) are added (andremoved) instances of security director 450 and/or enforcement points250 ₁-250 _(U) are added (and removed) to provide security.

FIG. 7 depicts method (or process) 700 for microsegmentation in datanetworks. In various embodiments, method 700 is performed by system 600(FIG. 6). At step 710, an enforcement point is provisioned. For example,an enforcement point of enforcement points 250 ₁-250 _(V) (FIG. 2)and/or 250 (FIGS. 3 and 4) is commissioned by management 650 (FIG. 6).By way of non-limiting example, the enforcement point can run on a baremetal server (e.g., physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1)), VM(e.g., of VMs 260 ₁-260 _(V) (FIG. 2)), and container (e.g., ofcontainers 340 ₁-340 _(z) (FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4)).The enforcement point may be communicatively coupled to a virtual switch(e.g., virtual switch 240 (FIGS. 2 and 3)) and security director 450(FIGS. 4 and 6). In some embodiments, the enforcement point can programthe virtual switch (e.g., when upon provisioning). For example, theenforcement point can program the virtual switch to direct all datacommunications (e.g., network packets such as IP packet) to theenforcement point in addition to or instead of their respectiveindicated destination (e.g., as indicated by a destination networkaddress such as an IP address, destination port, etc.).

At step 720, metadata is received. For example, security director 450(FIGS. 4 and 6) received metadata from orchestration layer 410 (FIG. 4).At step 730, a (high-level) declarative security policy is received. Asexplained above with respect to FIG. 4, the high-level declarativesecurity policy is an intent-driven model which defines groups of baremetal servers (e.g., physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1)), VMs(e.g., of VMs 260 ₁-260 _(V) (FIG. 2)), and containers (e.g., ofcontainers 340 ₁-340 _(Z) (FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4)),and describes permitted connectivity, security, and network servicesbetween groups. Since the declarative security policy is at a high levelof abstraction (e.g., compared to a firewall rule set), rules betweeneach and every single entity in a network are not needed (or desired).Instead, a statement/model in the high-level declarative security policycan be applicable to several entities in the network (e.g., in a group).

At step 740, a (low-level) firewall rule set is determined using thereceived metadata and the (high-level) declarative security policy. Forexample, analytics 630 (FIG. 6) compiles the (high-level) declarativesecurity policy using the received metadata from orchestration layer 410to generate a firewall rule set.

At step 750, an enforcement point applies the firewall rule set tocommunications through a network switch. For example, the enforcementpoint (e.g., of enforcement points 250 ₁-250 _(V) (FIG. 2) and/or 250(FIGS. 3 and 4)) can program virtual switch 240 (FIG. 3) such thatcommunications (e.g., network packets such as IP packets) are forwardedto their respective destination, dropped, or forwarded to an alternativedestination (e.g., honeypot, tarpit, canary trap, etc.).

Application of the firewall rule set as described above can be used tomicrosegment a data network. In other words, entities on the datanetwork (e.g., physical servers, VMs, containers, etc.) can be groupedinto segments, where communications among entities within a group arepermitted and optionally limited by such characteristics assource/destination ports, protocols used, applications used, the like,and combinations thereof. Communications among entities in differentgroups can be restricted, for example, not permitted at all and/orlimited by a more restrictive set of characteristics than are generallypermitted within a group. Since an enforcement point can be provisionedfor each network switch and each entity on the network communicatesthrough the network switch, the segmentation of the network (e.g.,division effectively into groups of any size) can be highly granular.Hence the data network can be said to be microsegmented. By way ofnon-limiting example, there is an enforcement point (e.g., ofenforcement points 250 ₁-250 _(V) (FIG. 2) and/or 250 (FIGS. 3 and 4))provisioned for each virtual switch (e.g., virtual switch 240 (FIGS. 2and 3)) and each container (e.g., of containers 340 ₁-340 _(Z) (FIG. 3)and 340 _(1,1)-340 _(W,Z) (FIG. 4)) communicates through the virtualswitch.

FIG. 8 is a non-limiting example of granular segmentation (e.g.,microsegmentation), according to various embodiments. A data networkcomprises a plurality of entities 800, such as bare metal servers (e.g.,physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1)), VMs (e.g., of VMs 260₁-260 _(V) (FIG. 2)), and containers (e.g., of containers 340 ₁-340 _(Z)(FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4)). The network entities 800are associated with Group A (denoted by “A”) or Group B (denoted by“B”). Communications between Group A and Group B are more restricted(e.g., for security reasons) and communications within Group B are lessrestricted (e.g., for business purposes).

As shown in FIG. 8, entities in Group B can be disposed throughoutnetwork 800 without limitation. For example, entities in Group B neednot be limited to entities connected to the same network server, runningon the same VM, running in the same physical server, running in physicalservers in the same rack, running in the same data center, and the like.Communication between Group A and Group B, and communication withinGroup B can still be controlled, regardless of where entities associatedwith Group B are disposed. The microsegment comprised of Group Bentities is denoted by microsegment 810.

As depicted in FIG. 8, separate networks (e.g., segments, microsegments,etc.) can be affected even though physically there is one network. Insome embodiments, a hierarchical network topology can be affected whenthe physical network topology is flat. In this way, the operation of a(flat) data network is altered to provide granular segmentation of thedata network.

FIG. 9 illustrates an exemplary computer system 900 that may be used toimplement some embodiments of the present invention. The computer system900 in FIG. 9 may be implemented in the contexts of the likes ofcomputing systems, networks, servers, or combinations thereof. Thecomputer system 900 in FIG. 9 includes one or more processor unit(s) 910and main memory 920. Main memory 920 stores, in part, instructions anddata for execution by processor unit(s) 910. Main memory 920 stores theexecutable code when in operation, in this example. The computer system900 in FIG. 9 further includes a mass data storage 930, portable storagedevice 940, output devices 950, user input devices 960, a graphicsdisplay system 970, and peripheral device(s) 980.

The components shown in FIG. 9 are depicted as being connected via asingle bus 990. The components may be connected through one or more datatransport means. Processor unit(s) 910 and main memory 920 are connectedvia a local microprocessor bus, and the mass data storage 930,peripheral device(s) 980, portable storage device 940, and graphicsdisplay system 970 are connected via one or more input/output (I/O)buses.

Mass data storage 930, which can be implemented with a magnetic diskdrive, solid state drive, or an optical disk drive, is a non-volatilestorage device for storing data and instructions for use by processorunit(s) 910. Mass data storage 930 stores the system software forimplementing embodiments of the present disclosure for purposes ofloading that software into main memory 920.

Portable storage device 940 operates in conjunction with a portablenon-volatile storage medium, such as a flash drive, floppy disk, compactdisk, digital video disc, or Universal Serial Bus (USB) storage device,to input and output data and code to and from the computer system 900 inFIG. 9. The system software for implementing embodiments of the presentdisclosure is stored on such a portable medium and input to the computersystem 900 via the portable storage device 940.

User input devices 960 can provide a portion of a user interface. Userinput devices 960 may include one or more microphones, an alphanumerickeypad, such as a keyboard, for inputting alphanumeric and otherinformation, or a pointing device, such as a mouse, a trackball, stylus,or cursor direction keys. User input devices 960 can also include atouchscreen. Additionally, the computer system 900 as shown in FIG. 9includes output devices 950. Suitable output devices 950 includespeakers, printers, network interfaces, and monitors.

Graphics display system 970 include a liquid crystal display (LCD) orother suitable display device. Graphics display system 970 isconfigurable to receive textual and graphical information and processesthe information for output to the display device.

Peripheral device(s) 980 may include any type of computer support deviceto add additional functionality to the computer system.

The components provided in the computer system 900 in FIG. 9 are thosetypically found in computer systems that may be suitable for use withembodiments of the present disclosure and are intended to represent abroad category of such computer components that are well known in theart. Thus, the computer system 900 in FIG. 9 can be a personal computer(PC), hand held computer system, telephone, mobile computer system,workstation, tablet, phablet, mobile phone, server, minicomputer,mainframe computer, wearable, or any other computer system. The computermay also include different bus configurations, networked platforms,multi-processor platforms, and the like. Various operating systems maybe used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID,IOS, CHROME, and other suitable operating systems.

Some of the above-described functions may be composed of instructionsthat are stored on storage media (e.g., computer-readable medium). Theinstructions may be retrieved and executed by the processor. Someexamples of storage media are memory devices, tapes, disks, and thelike. The instructions are operational when executed by the processor todirect the processor to operate in accord with the technology. Thoseskilled in the art are familiar with instructions, processor(s), andstorage media.

In some embodiments, the computer system 900 may be implemented as acloud-based computing environment, such as a virtual machine operatingwithin a computing cloud. In other embodiments, the computer system 900may itself include a cloud-based computing environment, where thefunctionalities of the computer system 900 are executed in a distributedfashion. Thus, the computer system 900, when configured as a computingcloud, may include pluralities of computing devices in various forms, aswill be described in greater detail below.

In general, a cloud-based computing environment is a resource thattypically combines the computational power of a large grouping ofprocessors (such as within web servers) and/or that combines the storagecapacity of a large grouping of computer memories or storage devices.Systems that provide cloud-based resources may be utilized exclusivelyby their owners or such systems may be accessible to outside users whodeploy applications within the computing infrastructure to obtain thebenefit of large computational or storage resources.

The cloud is formed, for example, by a network of web servers thatcomprise a plurality of computing devices, such as the computer system900, with each server (or at least a plurality thereof) providingprocessor and/or storage resources. These servers manage workloadsprovided by multiple users (e.g., cloud resource customers or otherusers). Typically, each user places workload demands upon the cloud thatvary in real-time, sometimes dramatically. The nature and extent ofthese variations typically depends on the type of business associatedwith the user.

It is noteworthy that any hardware platform suitable for performing theprocessing described herein is suitable for use with the technology. Theterms “computer-readable storage medium” and “computer-readable storagemedia” as used herein refer to any medium or media that participate inproviding instructions to a CPU for execution. Such media can take manyforms, including, but not limited to, non-volatile media, volatile mediaand transmission media. Non-volatile media include, for example,optical, magnetic, and solid-state disks, such as a fixed disk. Volatilemedia include dynamic memory, such as system random-access memory (RAM).Transmission media include coaxial cables, copper wire and fiber optics,among others, including the wires that comprise one embodiment of a bus.Transmission media can also take the form of acoustic or light waves,such as those generated during radio frequency (RF) and infrared (IR)data communications. Common forms of computer-readable media include,for example, a floppy disk, a flexible disk, a hard disk, magnetic tape,any other magnetic medium, a CD-ROM disk, digital video disk (DVD), anyother optical medium, any other physical medium with patterns of marksor holes, a RAM, a programmable read-only memory (PROM), an erasableprogrammable read-only memory (EPROM), an electrically erasableprogrammable read-only memory (EEPROM), a Flash memory, any other memorychip or data exchange adapter, a carrier wave, or any other medium fromwhich a computer can read.

Various forms of computer-readable media may be involved in carrying oneor more sequences of one or more instructions to a CPU for execution. Abus carries the data to system RAM, from which a CPU retrieves andexecutes the instructions. The instructions received by system RAM canoptionally be stored on a fixed disk either before or after execution bya CPU.

Computer program code for carrying out operations for aspects of thepresent technology may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as JAVA, SMALLTALK, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

FIG. 10 illustrates a simplified block diagram of system 1000, accordingto some embodiments. System 1000 may include events 1010, metadatasource 1020, policy 620, security director 1030, compiler 1040, andenforcement points 250 ₁-250 _(U).

In some embodiments, events 1010 involve workloads. For example,workloads are one or more of a: bare metal server (e.g., physical hosts160 _(1,1)-160 _(x,y) (FIG. 1)), VM (e.g., VMs 260 ₁-260 _(V) shown inFIG. 2), container (e.g., containers 340 ₁-340 _(z) (FIG. 3) and 340_(1,1)-340 _(W,Z) (FIG. 4)), and microservice. A microservice is anelement of functionality of an application. Microservices areindependently deployable (e.g., in various combinations of bare metalservers, virtual machines, and containers) and scalable. In contrast toa monolithic application having all of its functionality in one process,an application having a microservices architecture puts each element offunctionality into a separate microservice. When a monolithicapplication is scaled, the whole monolithic application is replicatedfor each instance. An application having a microservices architecturecan scale by distributing various combinations and permutations of itsmicroservices across the same or different workloads for each instance.

Events 1010 can include: a workload being instantiated/created 1012, aworkload being removed/deleted 1014, a workload being migrated 1016, anda workload's metadata being changed 1018. Workload instantiation 1012can include: a bare-metal server coming online, hypervisor 230 creatinga virtual machine (of VMs 260 ₁-260 _(V) in FIG. 2), container engine330 creating a container (e.g., of containers 340 ₁-340 _(z) (FIG. 3)and 340 _(1,1)-340 _(W,Z) (FIG. 4)), and the like, singly and incombination. A workload being removed 1014 can include: a bare-metalserver being taken offline, hypervisor 230 removing a virtual machine(of VMs 260 ₁-260 _(V) in FIG. 2), container engine 330 removing acontainer (e.g., of containers 340 ₁-340 _(z) (FIG. 3) and 340_(1,1)-340 _(W,Z) (FIG. 4)), and the like, singly and in combination.Workload migration 1016 can include: moving a particular instance of aworkload from one location to another. In some embodiments, a locationis at least one of a (particular) data center (e.g., data center 120 inFIG. 1), bare metal server, VM, container, and the like. By way ofnon-limiting example, workload migration includes moving a workload fromone physical host (e.g., of physical hosts 160 _(1,1)-160 _(x,y) (FIG.1)) to another physical host in data center 120. Workload metadatachanging 1018 can occur when a workload's metadata changes. For example,when a characteristic of an existing workload is changed, the change tothe particular characteristic (e.g., trusted/untrusted, Payment CardIndustry Data Security Standard (PCI DSS) compliant/not compliant, andthe like) can manifest as a change in the workload's metadata. Othertypes of events 1010 can be used.

When an event of events 1010 occurs, metadata source 1020 can generateand/or record event metadata concerning the event (e.g., event metadata)and provide the event metadata to security director 1030. Metadatasource 1020 can be one or more authoritative sources. For example,metadata source 1020 is hypervisor 230 in FIG. 2 (e.g., Microsoft®HyperV®, Microsoft® System Center Virtual Machine Manager,VMwarevCenter®, VMware ESX®/ESXi™, Oracle® VM server, Kernel-basedVirtual Machine (KVM), or Citrix® XenServer®, orchestration layer 410 inFIG. 4, enforcement points 250 ₁-250 _(U), and other sources of eventmetadata (information), singly or in combination. Additionally oralternatively, metadata source 1020 can be an authoritative data storewhich consolidates metadata from one or more sources such hypervisor230, orchestration layer 410, a time server, enforcement points 250₁-250 _(U), and the like.

In some embodiments, event metadata can be any information concerning aworkload, network, event, etc. that a user specifies. For example, eventmetadata can be specific to a particular workload (e.g., applicationname and/or service name (e.g., APP 350 ₁-350 _(z) in FIG. 3),(user-defined) tag/label, IP address, (active) ports, operating system,software version information, (geographic) location, and the like). Byway of further non-limiting example, event metadata (e.g., fromenforcement points 250 ₁-250 _(U)) includes a workload's IP address,media access control (MAC) address, and the like (e.g., using DynamicHost Configuration Protocol (DHCP) snooping), workload generatingnetwork traffic above a predetermined threshold, workload generatingsuspicious traffic, and the like. In various embodiments, metadata canbe general (e.g., not pertaining to a particular workload, such as adate, day of week, time, range of dates and/or times, work week,weekend, holiday, season, and the like) and/or a provision in thehigh-level declarative security policy is conditioned upon the generalmetadata. By way of non-limiting example, a high-level declarativesecurity policy provision is conditioned upon a present date falling ona weekend.

Security director 1030 can have at least some of the characteristicsdescribed for security director 450 in relation to FIGS. 4 and 6.Security director 1030 can be communicatively coupled to policy 620 andcompiler 1040.

Security director 1030 can also be communicatively coupled toenforcement points 250 ₁-250 _(U). For example, security director 1030disseminates respective low-level firewall rule sets to enforcementpoints 250 ₁-250 _(U), each firewall rule sets applicable to arespective one of enforcement points 250 ₁-250 _(U). Alternatively oradditionally, security director 1030 can update state information for aworkload. In some embodiments, when a workload migrates, the enforcementpoint (e.g., of enforcement points 250 ₁-250 _(U)) serving the workloadchanges, so the “new” enforcement point at the destination receivesstate information maintained by the “old” enforcement point at thesource. State information can be used to track established communicationsessions. For example, for TCP connections—established using a three-wayhandshake (e.g., “SYN, SYN-ACK, ACK”)—once enforcement point 250 ₁-250_(U) receives the workload's “ACK” response, it transfers the connectionto the “established” state. The “established” state determined by the“old” enforcement point will be sent to the “new” enforcement point, sothe TCP connection can continue without interruption (e.g., having toestablish the TCP connection again). In various embodiments, securitydirector 1030 receives information logged by enforcement points 250₁-250 _(U), as described above in relation to FIG. 6.

Enforcement points 250 ₁-250 _(U) were described above in relation toFIG. 6. Enforcement points 250 ₁-250 _(U) can additionally oralternatively filter network communications (e.g., data packets) usingapplication layer (e.g., Open Systems Interconnection model (OSI model)layer 7) characteristics, in accordance with a low-level firewall ruleset.

Policy 620 was described above in relation to FIG. 6. For example,policy 620 can include high-level declarative security policies. Asexplained above with respect to FIG. 4, the high-level declarativesecurity policy is an intent-driven model which defines groups of baremetal servers (e.g., physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1)), VMs(e.g., of VMs 260 ₁-260 _(V) (FIG. 2)), and containers (e.g., ofcontainers 340 ₁-340 _(Z) (FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG.4))—referred to as workloads—and describes permitted connectivity,security, and network services between groups. FIG. 11 illustratesnon-limiting examples 1100 of (application layer) high-level declarativesecurity policies. For example, policy 1110 denotes a group ofapplication server workloads App-Svr-Grp-1 can receive incomingconnections from internal users using HTTP and TCP through port 8080,and Hypertext Transfer Protocol Secure (HTTPS) and TCP through port8443, at address (Uniform Resource Identifier (URI))http://appl@xyz.com. By way of further non-limiting example, policy 1120denotes a group of database server workloads (DB-Svrs) may not makeoutbound connections to external users using FTP and TCP through port 21(e.g., such connections are dropped and logged) at any address.

Turning back to FIG. 10, compiler 1040 can compile high-leveldeclarative security policies into low-level firewall rule sets. Asnoted above, compilation is described further in related U.S. Pat. No.9,380,027 titled, “Conditional Declarative Policies” filed Mar. 30, 2015and issued Jun. 28, 2016, which is hereby incorporated by reference forall purposes. Compiler 1040 can run on a workload separate from securitydirector 1030 and/or run in the same workload as security director 1030.In some embodiments, compiler 1040 can be one or more of analytics 630(FIG. 6) and a workload.

FIG. 12 depicts method (or process) 1200 for granular segmentation of anetwork using events. In various embodiments, method 1200 is performedby security director 1030 (FIG. 10). At step 1210, event metadata abouta workload is received. In some embodiments, event metadata is receivedfrom metadata source 1020 (FIG. 10). For example, in response to anevent, metadata source 1020 sends corresponding event metadata.

At step 1220, a workload type is identified from the metadata. Forexample, the workload type can include: an application and/or servicerunning on the workload, a characteristic of the workload (e.g.,trusted/untrusted, Payment Card Industry Data Security Standard (PCIDSS) compliant/not compliant, and the like), user-defined tag/label,location (e.g., geographic such as from GeoIP, particular data center,etc.) and the like.

At step 1230, at least one high-level declarative security policyapplicable to the workload type is determined. When an applicablehigh-level declarative security policy applicable to the workload typecannot be determined (e.g., the workload is not subject toprotection/segmentation) then method 1200 continues back to step 1210(not shown in FIG. 12).

At step 1240, the at least one high-level declarative security policyapplicable to the workload type is received. For example, the at leastone high-level declarative security policy applicable to the workloadtype is received from policy 620 (FIGS. 6 and 10). As explained abovewith respect to FIG. 4, the high-level declarative security policy is anintent-driven model which defines groups of bare metal servers (e.g.,physical hosts 160 _(1,1)-160 _(x,y) (FIG. 1)), VMs (e.g., of VMs 260₁-260 _(V) (FIG. 2)), and containers (e.g., of containers 340 ₁-340 _(z)(FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4)), and describes permittedconnectivity, security, and network services between groups. Since thedeclarative security policy is at a high level of abstraction (e.g.,compared to a firewall rule set), rules between each and every singleentity in a network are not needed (or desired). Instead, astatement/model in the high-level declarative security policy can beapplicable to several entities in the network (e.g., in a group).

At step 1250, a low-level firewall rule set is generated. In someembodiments, compiler 1040 (FIG. 10) is launched to generate thelow-level firewall rule set using the event metadata and at least onehigh-level declarative security policy. For example, security director1030 can include compiler 1040 and produce the low-level firewall ruleset (e.g., security director 1030 receives the low-level firewall ruleset internally from compiler 1040). By way of further non-limitingexample, security director 1030 does not include compiler 1040 (e.g.,compiler 1040 is not integrated in or is external to security director1030), compiler 1040 is launched to generate the low-level firewall ruleset, and security director 1030 receives the low-level firewall rule setfrom compiler 1040 (not shown in FIG. 12).

At step 1260, the low-level firewall rule set is provisioned to at leastone enforcement point (e.g., at least one of enforcement points 250₁-250 _(V) (FIG. 2), 250 (FIGS. 3 and 4), and 250 ₁-250 _(U) (FIG. 10)).The enforcement point can apply the low-level firewall rule set. Forexample, the enforcement point will forward communications (e.g.,network packets such as IP packets) to their respective destination,drop them, or forward them to an alternative destination (e.g.,honeypot, tarpit, canary trap, etc.) in accordance with the low-levelfirewall rule set.

In various embodiments, an enforcement point can apply the low-levelfirewall rule set to communications through a network switch, such as ahardware switch (e.g., ToR switch 150 ₁-150 _(X) (FIG. 1)), virtualswitch (e.g., virtual switch 240 (FIG. 3)), router, hardware firewall(e.g., firewall 130 (FIG. 1)), and the like. For example, theenforcement point can program a network switch to direct all datacommunications (e.g., network packets such as IP packets) to theenforcement point in addition to or instead of their respectiveindicated destination (e.g., as indicated by a destination networkaddress such as an IP address, destination port, etc.). Alternatively oradditionally, the enforcement point can program the network switch suchthat communications (e.g., network packets such as IP packets) areforwarded to their respective destination, dropped, or forwarded to analternative destination (e.g., honeypot, tarpit, canary trap, etc.).

Application of the firewall rule set as described above can be used tosegment a data network granularly. In other words, entities on the datanetwork (e.g., physical servers, VMs, containers, microservices, etc.)can be grouped into segments, where communications among entities withina group are permitted and optionally limited by such characteristics assource/destination ports, protocols used, applications used, servicesperformed/provided, the like, and combinations thereof. Communicationsamong entities in different groups can be restricted, for example, notpermitted at all and/or limited by a more restrictive set ofcharacteristics than are generally permitted within a group. Since anenforcement point can be provisioned for each network switch and eachentity on the network communicates through the network switch, thesegmentation of the network (e.g., division effectively into groups ofany size) can be highly granular. Hence the data network can be said tohave granular segmentation. By way of non-limiting example, there is anenforcement point (e.g., of enforcement points 250 ₁-250 _(V) (FIG. 2)and/or 250 (FIGS. 3 and 4)) provisioned for each virtual switch (e.g.,virtual switch 240 (FIGS. 2 and 3)) and each container (e.g., ofcontainers 340 ₁-340 _(Z) (FIG. 3) and 340 _(1,1)-340 _(W,Z) (FIG. 4))communicates through the virtual switch. FIG. 8 described aboveillustrates granular segmentation.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present technology has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Exemplaryembodiments were chosen and described in order to best explain theprinciples of the present technology and its practical application, andto enable others of ordinary skill in the art to understand theinvention for various embodiments with various modifications as aresuited to the particular use contemplated.

Aspects of the present technology are described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present technology. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The description of the present technology has been presented forpurposes of illustration and description, but is not intended to beexhaustive or limited to the invention in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the invention.Exemplary embodiments were chosen and described in order to best explainthe principles of the present technology and its practical application,and to enable others of ordinary skill in the art to understand theinvention for various embodiments with various modifications as aresuited to the particular use contemplated.

What is claimed is:
 1. A method implemented by at least one hardwareprocessor for granular segmentation of data networks, the methodcomprising: receiving from a metadata source event metadata associatedwith a workload; identifying a workload type using the event metadata;determining a high-level declarative security policy using the workloadtype; launching a compiler to generate a low-level firewall rule setusing the high-level declarative security policy and the event metadata;and configuring by a plurality of enforcement points a respectivenetwork switch of a plurality of network switches to process packets inaccordance with the low-level firewall rule set, the plurality ofnetwork switches being collectively communicatively coupled to aplurality of workloads, such that network communications between a firstgroup of workloads of the plurality of workloads and the workload arenot permitted, and between a second group of workloads of the pluralityof workloads and the workload are permitted.
 2. The method of claim 1,wherein the metadata source is at least one of a hypervisor and anorchestration layer.
 3. The method of claim 1, wherein the eventmetadata is received in response to an event.
 4. The method of claim 3,wherein the event is at least one of: the workload being instantiated,the workload being removed, the workload being migrated, and workloadmetadata being changed.
 5. The method of claim 4, further comprising:disseminating, to a destination enforcement point of a migratedworkload, a state of a communications session of the migrated workload.6. The method of claim 1, wherein the workload is at least one of a:bare-metal server, virtual machine (VM), container, and microservice. 7.The method of claim 1, wherein the event metadata includes at least oneof: an event, an application name, a service name, a user-definedtag/label, an IP address, a port number, an operating system name, asoftware version, and a location.
 8. The method of claim 1, wherein: theevent metadata includes at least one of: a date and a time; and thehigh-level declarative security policy includes a time-based provision.9. The method of claim 1, wherein the high-level declarative securitypolicy comprises an intent-driven model, the intent-driven modelspecifying groups of workloads and describing permitted connectivity,security, and network services between the groups.
 10. The method ofclaim 1, wherein the low-level firewall rule set comprises individualworkload addresses to and/or from which network communications are atleast one of forwarded, blocked, redirected, and logged.
 11. A systemfor granular segmentation of data networks, the system comprising: atleast one hardware processor; and a memory coupled to the at least onehardware processor, the memory storing instructions executable by the atleast one hardware processor to perform a method comprising: receivingfrom a metadata source event metadata associated with a workload;identifying a workload type using the event metadata; determining ahigh-level declarative security policy using the workload type;launching a compiler to generate a low-level firewall rule set using thehigh-level declarative security policy and the event metadata; andconfiguring by a plurality of enforcement points a respective networkswitch of a plurality of network switches to process packets inaccordance with the low-level firewall rule set, the plurality ofnetwork switches being collectively communicatively coupled to aplurality of workloads, such that network communications between a firstgroup of workloads of the plurality of workloads and the workload arenot permitted, and between a second group of workloads of the pluralityof workloads and the workload are permitted.
 12. The system of claim 11,wherein the metadata source is at least one of a hypervisor and anorchestration layer.
 13. The system of claim 11, wherein the metadatasource sends the event metadata in response to an event.
 14. The systemof claim 13, wherein the event is at least one of: the workload beinginstantiated, the workload being removed, the workload being migrated,and workload metadata being changed.
 15. The system of claim 14, whereinthe method further comprises: disseminating, to a destinationenforcement point of a migrated workload, a state of a communicationssession of the migrated workload.
 16. The system of claim 11, whereinthe workload is at least one of a: bare-metal server, virtual machine,container, and microservice.
 17. The system of claim 11, wherein theevent metadata includes at least one of: an event, an application name,a service name, a user-defined tag/label, an IP address, a port number,an operating system name, a software version, and a location.
 18. Thesystem of claim 11, wherein: the event metadata includes at least one ofa date and a time; and the high-level declarative security policyincludes a time-based provision.
 19. The system of claim 11, wherein thehigh-level declarative policy comprises an intent-driven model, theintent-driven model specifying groups of workloads and describingpermitted connectivity, security, and network services between thegroups.
 20. The system of claim 11, wherein the low-level firewall ruleset comprises individual workload addresses to and/or from which networkcommunications are at least one of forwarded, blocked, redirected, andlogged.